Various classes of graphical models describe computations that can be performed on application specific computational hardware, such as a computer, microcontroller, FPGA, and custom hardware. Classes of such graphical models may include time-based block diagrams such as those found within Simulink® version 6.3 (R14sp3) from The MathWorks, Inc. of Natick, Mass., state-based and flow diagrams such as those found within Stateflow® from The MathWorks, Inc. of Natick, Mass., physical models such as those found within SimMechanics from The MathWorks, Inc. of Natick Mass., entity flow network diagrams such as those found within SimEvents from The MathWorks, Inc. of Natick, Mass., discrete-event based diagrams, data-flow diagrams, and software diagrams such as those within the Unified Modeling Language (UML). A common characteristic among these various forms of graphical models is that they define semantics on how to interpret or execute the model.
In modeling a system in a graphical modeling environment, the system to be modeled is described using blocks and lines. Usually, the blocks define operations, represent mathematical equations, or contain state information. The lines or signals can be used to carry information, describe dependencies, or define relationships between the blocks. The lines can also have operations or mathematics associated with them. There are many graphical modeling domains, each with its own semantics that dictate what the models mean and how the models can be executed or translated to an execution environment. Conventional graphical modeling environments often have a great deal of freedom in how models are executed. For example, in time-based block diagrams, blocks are typically ordered (sorted) as part of the preparation of a model for execution. The ordering does make use of some of the signals, but in general there are a large number of valid sorts that will all yield the same (correct) answer. This freedom results in widely varying executions of models that are functionally equal. These variations can cause confusion in analysis of model execution or inspection of the execution environment.
Conventional modeling environments allow a user to add dependencies between blocks via explicit (extra) lines or textual information, such as the priorities and placement groups provided in Simulink®. A block priority specifies the order in which the equations associated with a block are evaluated with respect to other blocks. Placement groups are a way of causing each class of block methods for a specified set of blocks to be “placed together” in the block method execution lists. These means are, however, cumbersome to use and fall short of achieving desired results in a short period of time. In particular, the block sorting priorities fall short of enabling the user to specify execution dependencies that can be understood and managed at the model-wide level. Moreover, this explicit specification of the extra dependencies hurts the readability of the diagram. Therefore, it is desired to provide new methods and systems for controlling the model execution without graphically (pictorially) altering the visual representation of the model by providing non-graphical model dependencies to establish the desired execution behavior of models.